其他
业务数据治理体系化思考与实践
总第508篇
2022年 第025篇
一、序言
二、背景介绍
三、治理体系化思考
3.1 什么是数据治理体系化?
3.2 数据治理体系化如何解决目前治理存在的问题?
3.3 业务数据管治体系框架如何建设?
3.4 体系框架如何落地实施?
四、治理体系化实践
4.1 标准化
4.2 数字化
4.3 系统化
五、业务数据治理实施流程
六、总结与展望
一、序言
二、背景介绍
认知不一致,思路不统一:治理缺乏通用的体系指引,不同的治理人对于数据治理的认知深度、问题拆解的方式、治理的思路步骤、采取的方法及其效果追踪等方面,都存在较大的差异。 重复治理、信息不通:治理不彻底、治理经验缺乏沉淀,同样的治理,不同的人反复实行。 范围交叉、边界不清、效果难评估:不同的人针对不同的问题成立不同的专项进行治理,问题的底层逻辑有交叉。有的治理没做什么动作,反而收到了较好的结果,有的治理对于结果说不清。
流程规范缺失:对于每个方向、每类问题的治理缺少理论指导,治理的方法、动作、流程、步骤依赖治理人的经验和判断。 问题难度量追踪:治理的问题缺少衡量标准,更多靠人为来进行判断,治理效果缺少评估体系。 解决方案难落地:解决方案存在于文档中,需要治理人查找理解,缺少工具支撑,成本较高。
治理线上化程度低:治理依赖的资产信息、治理动作都分散于多个系统中,信息碎片化,执行效率低。 过程无法标准化,结果无保障:治理过程需要治理人来“人为保障”,存在理解偏差和执行偏差。
缺乏整体顶层治理方案设计:业务及数据中心对于数据治理的要求,需要治理更全面、更精细、更有效,需要治理的体系化,需要从宏观角度进行思考,层层拆解,需要从整体、从顶层来做方案设计。 问题越来越复杂,单点难解决:过往更多的是从表象去解决问题,从表面来看衡量指标有改善,实际是“头痛医头、脚痛医脚”,并没有从根本上解决问题。或者多个问题具有共性,根本问题是一致的。比如查询资源紧张的根本,可能是分析主题模型建设不足或运营不够。 不同问题的优先级无法确定:不同问题的优先级缺乏衡量标准和方法,主要靠人为判断。 治理不符合MECE原则:每个治理方向由哪些问题组成,哪些最重要,哪些的ROI最高,哪些问题和治理动作可以合并,同一问题在数仓不同主题、不同分层的衡量标准和治理方法应该有哪些差异,都需要在体系化治理中进行考虑。
三、治理体系化思考
3.1 什么是数据治理体系化?
3.2 数据治理体系化如何解决目前治理存在的问题?
方式方法上:先做顶层治理框架设计,从团队整体视角定义和规划好治理的范围、人员、职责、目标、方法、工具等必须部分,再进行落地。更关注整体策略的普适性及有效性,而非深陷某个具体问题解决方案开始治理。 技术手段上:以完善的技术研发规范为基础,以元数据及指标体系为核心,对业务数仓和数据应用进行全面评价和监控,同时配套治理系统工具,帮助治理同学落地治理策略和解决数据开发同学治理效率低问题。 运营策略上:通过对待治理问题进行影响范围、收益情况进行评估,确定待治理问题的重要度,从管理者视角以及问题责任人视角2个途径推动不同重要程度的治理问题解决。
3.3 业务数据管治体系框架如何建设?
管理层:立法,制定相关的组织保障流程规范、职责设计、奖惩措施,指导和保障数据治理顺利进行,这是数据治理能够成功启动运转的关键因素。 标准层:设标准,制定各类研发标准规范、解决方案标准SOP等数据治理过程中需要的各类技术规范和解决方案,这是所有技术问题正确与否的重要依据,也是治理中事前解决方案必不可少的一部分。完善的标准规范和良好的落地效果,可很好地降低数据故障问题的发生量。 能力层:完善能力,主要是基于元数据的问题度量的数字化能力,以及问题工具化检测和解决的系统化能力。数字化和系统化能力是数据治理实施的科学性、实施的质量及效率的重要保障。 执行层:设定动作,结合要达成的具体目标,对各治理域问题,按照事前约束、事中监控、事后治理的思路进行解决。目标的达成,需要拆分到7大治理域相关的具体问题中去落地。因此,一个治理目标的达成,很依赖治理域对问题描述的全面性及深度。 评价层:给出评价,基于指标的问题监控,健康度评价体系,专项评估报告,评价治理收益及效果,这是实施治理推进过程监控,结果检验的重要抓手。 愿景:长期治理目标,指导数据管治有方向地不断朝着最终目标前进。
3.4 体系框架如何落地实施?
四、治理体系化实践
4.1 标准化
流程规范缺失:各个环节缺少标准和约束来指导规范化操作,无法有效杜绝问题的发生、解决。 落地条件差:规范标准、SOP等不具备落地条件,靠主观意愿,无法有效落地,效果差。 建设方法不合理:规范建设Case by Case,缺少体系化建设思路导致“一直建、一直缺”。
4.1.1 规范建设
数据治理管理规范:明确数据治理组织职责以及人员构成,确定数据治理实施流程及治理问题运维流程,以保障数据治理过程顺利进行。 数据研发规范:明确数据开发各个环节需要遵守的规范要求,从问题产生的源头,通过建设完善的研发规范,指导研发工作按标准进行,一定程度上可减少问题发生。 数据标准化治理SOP:明确各个治理问题治理动作,确保治理动作是标准且可实施。 数据健康度评估规范:明确治理效果的评价标准,对数据体系做到长期,稳定及指标化的衡量。
4.1.2 工具保障
标准规范可视化-知识中心
规范找不着:重要规范文档散落在各个Wiki空间,导致使用时无法快速查找,效率低下。 规范质量差:文档没有统一进行维护,无法持续进行迭代和完善,不能随着业务及技术的发展更新。 规范没权限:文档散落在各个成员的私人空间内部,未对所有人开通权限,优质内容无法及时共享。
测试规范工具化-八卦炉
治理提效保质工具-SOP自动化工具
治理效率低:需要根据SOP中治理经验,去各个平台分别执行相应治理动作,对于一些步骤较为复杂的SOP,需要跳转多个平台操作,治理效率较低。 治理过程无法约束:治理经验浮于文字,无法约束数据工程师的执行动作,导致部分问题治理不彻底。
4.1.3 标准化收益及建设经验
实现了数据开发、数据治理的标准化,解决了团队内各小组之间在开发、管理、运维方面流程方法标准不一致的问题。 通过测试工具对标准化测试规范进行落地,在事前阻塞问题发生,提升数据质量,减少故障发生。 通过SOP自动化工具,有效保障治理过程的标准化,解决了治理效果差的问题。
标准规范如何落地,需成为标准流程规范建设的一部分,最好有交付物。 标准规范的制定,除常规内容外,需要综合考虑组织目标、组织特点、已有工具、历史情况、用户反馈等因素,否则会给人“不接地气”的感觉。 标准规范的制定要优先考虑利用和适配已有工具能力,借助工具落地,而非让工具适配流程规范。
4.2 数字化
4.2.1 数字化架构设计方案
4.2.2 元数据仓库建设
数据业务化:即将数据工程师日常数据开发工作业务化描述,抽象多个业务过程,如需求提出、任务开发、数据表产出、数据应用、需求交付。 业务数字化:用建设业务数仓的思路和方法,对数据业务化之后的各个业务过程及主题,搭建元数据数仓及指标衡量体系,并通过元数据场景化应用提升易用性及丰富度。 数字应用化:在元数据仓库基础上开发数据产品,驱动数据管治实施。
业务元数据:基于具体业务逻辑元数据,常见业务元数据包括业务定义、业务术语、业务规则、业务指标等。 技术元数据:描述了与数据仓库开发、管理和维护相关数据,包括数据源信息、数据仓库模型、数据清洗与更新规则、数据映射和访问权限等,主要为开发和管理数据仓库的工程师使用。 管理元数据:描述管理领域相关概念、关系和规则的数据,主要包括管理流程、人员组织、角色职责等信息。
4.2.2 指标体系建设
生命周期视角:从数据本身出发,衡量数据从生产到销毁的各个过程,包括定义、接入、处理、存储、使用、销毁等等。 团队管理目标视角:根据团队管理核心要达成的目标分类,包括质量、效率、成本、安全、易用性、价值等等。 问题对象视角:根据治理问题核心关注的对象分类,包括安全、资源、服务、架构、效率、价值、质量等等。
技术类指标:覆盖成本、质量、安全、价值及易用性5个方面共57个指标。 需求类指标:覆盖新增、响应、开发、上线及验收等7个方面共36个指标。 故障类指标:覆盖故障发现、原因定位及处理环节共19个指标。
团队管理:帮助团队管理者快速了解团队情况,提升管理效率。 数据治理:利用元数据及指标体系驱动数据治理,为数据治理提供可量化的抓手。 项目评估:帮助项目成员准确评估项目的问题、进展及收益。
指标体系既要解决管理者对日常工作无抓手的问题,也要成为具体问题处理人员的治理抓手,兼顾管理者和开发者。 指标体系是展示偏整体层面的内容,还需通过指标解决实际问题,形成指标体系和数据治理工具闭环,实现发现问题、治理问题、衡量结果持续循环。 优先确定团队总体发展目标,从目标拆分设定指标,指标尽量覆盖不同业务线不同发展阶段。 业务需要明确自己所处阶段,针对不同阶段,制定考核目标,衡量阀值,既统一了衡量标准,又中和了大家考核标准。 指标需注意分层建设,避免“胡子眉毛一把抓”,便于适配目前的组织结构,也便于划分责任与定位。 基础指标体系建设完成后,可作为平时管理和工作的抓手,作为项目发起的依据,作为项目结果评估的手段。
4.2.3 资产等级建设
只能评经验判断哪些是核心资产,遇到问题无法评估解决的优先级。 核心链路的保障,比如SLA及DQC的配置范围缺少科学的评估手段。 管理者对团队核心资产缺乏准确的判断,无法准确有效的做出管理动作。
资产等级建设(数据表)
1)确定影响因子及权重评估
下游类型:决定下游资产重要程度,下游资产类型一般有ETL任务和数据产品两类,ETL任务及数据产品又根据重要度分为普通型及VIP型。 下游数量:决定是否是关键节点,对下游生产的影响范围,下游数量越多表明影响范围越大。 使用热度:决定是否有用,影响查询用户的范围,热度越高表明影响的用户范围越广。 链路深度及分层:决定问题的修复时间,链路越深,问题修复的时间可能就越长。
2)计算资产等级得分
3)资产等级映射
资产等级应用场景(数据表)
4.3 系统化
4.3.1 数据百品-管治中心
数据资产无法统计和描述,管理者及数据工程师不知道有什么,缺乏资产的可视化。 管理者缺少抓手发现团队的问题,且问题难以追踪。 治理线上化程度低,需要跳转多个工具,治理效率低,治理过程无法标准化,导致结果无法保障。
资产全景
资产大盘:从业务线管理者视角出发,展示了业务线内各类资产概览,帮助管理者一站式快速了解组内数据资产,无需跳转多个平台。 资产目录:展示团队数据各资产类型及明细,为数据RD数据使用提供信息支撑,提升RD数据探查效率。 个人资产:从归属人视角,展示数据RD个人及小组名下数据资产数量和资产类型及数据明细,详细描述个人资产信息。
管理中心
管理手段多依赖经验判断,当团队需求承接增加、团队人数增加时会带来管理难度的提升,管理者缺少抓手快速看到团队的整体情况。 管理动作天级别。管理者发现团队某核心指标异常(例如:故障数),需要找对应的责任人询问,无法从系统上快速进行异常追踪,原因获取。
管理者大盘:向管理者提供团队核心指标总览、问题趋势分析、异常明细追踪、异常原因标记等功能,方便管理者快速了解团队情况,及时做出管理动作。 需求管理:提供详细的人效分析大盘以及需求管理功能,服务于人效管理及提效。 故障管理:提供详细的故障分析大盘以及故障复盘管理能力,提升故障管理效率。 团队运营:团队周月报,值班,满意度问卷等团队运营需要的能力,提升运营效率。
治理中心
不了解分配给自己的待治理问题背景、目标和重要程度。治理工作成为盲目去完成分配的任务,即使完成了治理动作,可能依然无法保证是否真正达到治理目标,尤其是面对同时需要处理多类治理问题时,效果差。 数据治理解决问题时通常要使用各类工具互相辅助才能解决,问题多了之后,治理问题变成了重复使用不同的工具,严重影响治理效率和效果。
治理概览:治理中心首页,介绍了团队数据治理体系框架及标准化治理成果,让使用者在认知上与治理中心的治理理念一致,并提供数据治理优秀解决方案。 分析评估:对七大类治理问题进行量化评估,提供治理优先级及问题排名,让用户了解应该先做什么。 问题治理:提供丰富治理指标,全面衡量治理问题,问题分配及时通知,并利用SOP自动化工具,实现对解决问题过程的标准化,保障治理效果,提高治理效率。 进度监控:提供问题治理进度看板及问题分配进度监控,便于管理者宏观把控问题治理进度,合理规划分配节奏。
4.3.2 SOP自动化工具
SOP一般以Wiki形式存在,实际执行过程无法跟踪约束。 SOP动作的执行需要跳转多个平台系统,执行效率低下。
建设方案
基础组建层:SOP最小粒度模块,包括展示类组件(富文本、表格、IFrame),逻辑控制类组件(单选、多选),用户可根据SOP内容选择多个基础组件组合。 配置层:配置SOP中使用参数信息及执行步骤。 应用层:SOP最终效果展示,通过URL接口对外提供服务,比如治理中心可调用SOP工具接口实现一站式治理能力。
应用场景
4.3.3 经验总结
系统化是将解决问题的方法从线下到线上,从散点动作到连贯动作的一种有效解决方案。 没有完美的系统,也不必追求完美,考虑投入产出比,快速解决主要矛盾,应用到具体问题解决中。 产品定位设计,产品长远规划的能力设计尤为重要,否则容易出现“做着做着不知道做什么,不知道往什么方向发展”的情况。
五、业务数据治理实施流程
STEP 1:发现问题和制定目标,发现问题要从业务数据开发团队的视角出发,围绕服务好业务、遵守数据研发规范、收集好用户反馈,尽可能全地发现和收集相关需要解决的问题。同时,制定的目标要具备可实现性。 STEP 2:针对问题进行拆解,设计可衡量的指标,并通过元数据的采集建设进行实现,用做对目标的进一步量化,并作为实施过程监控及治理抓手。 STEP 3:对衡量出来的具体问题,制定相关的解决SOP,并且检查相应的研发标准规范是否完善,通过问题发生的事前、事中、事后几个阶段,建设或完善相应的工具化解决问题的能力。 STEP 4:推广运营,以拿结果为核心目标,针对不同角色运用不同策略,重点关注问题解决过程是否会与用户利益发生冲突,控制好节奏,根据问题的重要程度有规划地进行解决。 STEP 5:总结沉淀方法论,迭代认知,持续探索问题的最优解,优化治理方案和能力。
六、总结与展望
七、作者简介
阅读更多